You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add yourself to CONTRIBUTORS if you are a new contributor.
Write a good description on what the PR does.
Type of Changes
Type
✓
🔨 Refactoring
Description
This fixes the CI issues we were seeing in #5778 and #5805.
The second argument of these tuples is used to determine the number of jobs. However, the Linux runner only has two cores available. I'm not sure why this is different on Linux and Windows, but I think because we were trying to use more processes than available cores the test became either very slow or completely locked up.
You can see that we these changes both #5778 and #5805 pass the tests in expected times on all environments.
We could I think. It might make sense, although I'm not sure if there is a difference between organisations' and individual runners and if those could affect run time (I don't think so).
We could I think. It might make sense, although I'm not sure if there is a difference between organisations' and individual runners and if those could affect run time (I don't think so).
AFAIK the main / only difference is the number of concurrent runners.
@Pierre-Sassoulas No! This needs to be merged first as this is what's causing all the time outs. Subsequently we can rebase all the dependabot PRs and revert #5755.
Haven't looked at the code yet, but I don't think that PR fixes this. I believe the way this test is invoked sets the number of jobs automatically to 10 (or 5). That PR is referring to when jobs is set to 0, which makes pylint try to figure it out itself. That's a different case I believe.
Btw, thinking about this: should we check if there are two cores available as well? I feel like that's a bare minimum for any test runner nowadays, but that could still crash/hang these tests..
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
MaintenanceDiscussion or action around maintaining pylint or the dev workflow
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DanielNoord
added
the
Maintenance
Type of Changes
Description
This fixes the CI issues we were seeing in #5778 and #5805.
The second argument of these tuples is used to determine the number of jobs. However, the Linux runner only has two cores available. I'm not sure why this is different on Linux and Windows, but I think because we were trying to use more processes than available cores the test became either very slow or completely locked up.
You can see that we these changes both #5778 and #5805 pass the tests in expected times on all environments.